Cellular networks for mobile communications are nowadays ubiquitous, and most densely populated parts of the world are already covered by at least one cellular network service. Since both user equipment—such as mobile phones or terminals—and infrastructure equipment of cellular type networks is highly standardized, respective components and devices are already available at reasonable cost. This allows for widespread use of such networks in developed as well as in developing countries.
In addition to these “consumer”-type cellular networks, there exists a large number of mobile communication systems that are exclusively for use by local or regional authorities or for government use only. Such mobile communication systems include radio communication services for use by the police, military, civil protection and emergency response services, such as fire brigades and medical first response services and the like. As such systems usually enjoy a somewhat higher priority as compared to consumer mobile communication, these systems have hitherto been implemented as discrete and independent communication networks and services, for example in form of analogue frequency modulation (FM-) based radio communication networks.
However, such systems often do not comply with modern requirements, since such conventional radio communication systems may be prone to eavesdropping with the result that virtually anybody can listen to police and/or emergency service conversations, and, as a consequence, access to confidential and/or private information is not securely restricted. Furthermore, conventional radio communication systems may also suffer from coverage problems in that local weather or also geographical conditions bar some regions from access to these networks and services. In this way, it may occur that a police car—although inside an area of administrative responsibility—is unable to use the communication service and to communicate with, for example, the respective headquarters.
In addition to the above, conventional radio communication systems used by authorities are often outdated since they rely on old equipment, which may also be specialized equipment being relatively expensive and cost-intense for maintenance and expansion. However, at the same time, modern cellular communication networks have evolved and provide widespread service of high-quality mobile communication. Moreover, cellular communication networks may offer far better service coverage, independence from weather conditions, and also the possibility to encrypt communication in order to render eavesdropping difficult or even impossible. As a consequence, there is the tendency to migrate communication systems for authorities and public services to existing cellular networks for mobile communication.
Since, however, respective communication of public services should be somewhat prioritized with respect to consumer communication applications, the concept of so-called National Security and Emergency Preparedness calls, in short: NS/EP-calls, has evolved in order to provide higher priority at the time of call setup to such calls and ensuring an maximum quality of service with respect to standard consumer calls. More specifically, the concept of NS/EP-calls allows users to obtain priority access to respective radio and/or infrastructure resources of the communication networks, such as radio traffic channels, media gateway resources, and trunk access.
NS/EP-calls can further be distinguished into two groups, namely into so-called Wireless Priority Service (WPS) calls and so-called Government Emergency Telecommunication Service (GETS) calls. In the former case of WPS calls, there is usually a respective WPS prefix dialed in front of the B-number in order to gain priority access to network resources, and the GETS calls can be invoked in the Mobile Switching Center (MSC) or Visitor Location Register (VLR) of the respective communication network even without any subscription data. GETS calls are usually invoked by dialing a respective GETS destination number for an originating call or by forwarding to a GETS number.
In other words, with an increasing number of NS/EP personnel and public services relying on cell phones while performing their emergency and/or authority duties, priority is granted for emergency calls made from cellular telephones and/or other related mobile communication equipment. Usually, in situations in which a cellular network operates under normal conditions, priority access may not provide any improved quality of service since resource availability allows for establishing a further call communication without any problems.
However, once network load increases, the situation may occur that parts of the radio and/or infrastructure resources, or a communication network as a whole, is in a so-called congested state, in which establishing a further call communication has become impossible. Similar problems occur, when parts of the network resources suffer from a breakdown caused by emergency situations such as natural disasters. In this way, the cause of diminished availability of network resources may also disadvantageously coincide with an increased need for network resources, in case, for example, natural events have destroyed parts of the network infrastructure, said natural events, however, requiring at the same time an increased, or at least a minimum, capacity of communication for event handling and disaster management.
As far as the implementation of cellular communication networks is concerned, modern standards, such as the specification as standardized by the Third Generation Partnership Project (3GPP, release 8), support so-called AoIP, in which the user plane of the GSM A-interface is carried over IP transport (Internet Protocol) instead of TDM (Time Division Multiplexing). Data communication over IP, however, requires that both ends of the communication are provided with each network address of the respective communication partner. Another difference between AoIP and AoTDM lies in that AoIP involves a two-step process for handling media gateway resources, namely, so-called reserve RTP (Real Time Protocol) connection point procedures and configure RTP connection point procedures.
FIG. 1A shows schematically a possible conventional way of call setup in a packet-based communication network that employs for user plane data communication, for example, IP. As shown in FIG. 1A, a mobile terminal 1, such as a cellular phone of NS/EP personnel, may send a call request 100 to a call request entity 10. In response to this, the call request entity 10 sends a call setup request message 101 to a call switching entity 20 that is responsible for call switching and preparing call communication in the packet-based communication network (the call switching entity 20 may acknowledge this by sending a call proceeding message 102 back to the call request entity 10). For this purpose, the call switching entity 20 sends a request message 111 (e.g. an ADD.Req-message) to a first network entity 31, for example a media gateway (MGW), that is selected to handle data flow from the call request entity 10 to a remote end (not shown). By means of a respective response message 112 (e.g. ADD.Rep) the first network entity 31 provides its own transport layer address as a first network address to the call switching entity 20.
The first network address of the first network entity 31 is then forwarded to the call request entity 10 with an assignment request message 121 (e.g. the respective BSSMAP message). In this way, the call request entity 10 now is in possession of the network address of the first network entity 31. Subsequently, the call request entity 10 provides its own transport layer address as a second network address with an assignment complete message 122 to the call switching entity 20. Once the call switching entity 20 has forwarded the second network address of the call request entity 10 to the first network entity 31 by a second request message 131 (e.g. MOD.Req), the first network entity 31 acknowledges reception thereof by a second response message 132 (e.g. MOD.Rep). Now both involved entities, the call request entity 10 and the first network entity 31 are in possession of the network address of the respective communication partner, and call communication and/or transport layer data transfer may commence.
However, as already mentioned above, cellular networks may suffer from congestion due to the increased call volume and/or damage to respective network infrastructure. This, however, may severely affect the ability of NS/EP personnel to make emergency calls and handle their communication via the cellular network. Therefore, WPS and GETS provide a priority treatment for call setup in AoIP, by means of so-called Media Gateway Polling (MGW-Polling). Such polling may include queuing calls in a call request entity, such as a Base Station Controller (BSC).
As shown in FIG. 1B, there may be the possibility that an attempt to establish a call communication between the call request entity 10 and the first network entity 31 fails, and the call switching entity 20 selects a second network entity 32 as part of said media gateway polling for establishing a connection between this second network entity 32 and the call request entity 10. As shown, the first network entity 31, in response to receiving the request message 111 (e.g. ADD.Req), may respond to the call switching entity 20 by a failure-state response message 112′ (e.g. an ADD.Rep-message with an error code) that it is not available for communication.
In this case, the call switching entity 20 subsequently selects a second network entity 32 and sends a respective request message 111′ (e.g. ADD.Req) to the second network entity 32. This entity 32 replies then with a response message 112″ (ADD.Rep) forwarding its own transport layer address as a further network address to the call switching entity 20. The call switching entity 20 then forwards the further network address to the call request entity 10 (message 121), and the transport layer address of the call request entity 10 (second network address) is forwarded to the second network entity 32 (messages 122, 131), such that a call communication between the call request entity 10 and the second network entity 32 can be established. In general, call communication between the call request entity 10 and one of the network entities 31, 32, implies that both involved entities are in possession of the network address of the communication partner. In this way, it is the duty of the call switching entity 20 to facilitate network address exchange between the involved entities.
In this way, a call communication for a priority call originating from a prioritized mobile terminal 1 can be established although the first network entity 31 was not available for call communication. By means of immediately selecting another network entity, such as the shown second network entity 32, the call switching entity 20 provides prioritized call establishment for the mobile terminal 1. It is noted that in the situation of FIG. 1B, a conventional non-prioritized mobile terminal (consumer mobile phone), would have received a call reject message after the failure message 112′ from the first network entity 31. In other words, media gateway polling is usually not conducted for non-prioritized mobile devices, for which it is accepted that the respective user receives a respective error message and needs to initiate another call attempt from the start. In this way, however, media gateway polling provides prioritized access to respective mobile devices for establishing NS/EP-calls.
Media gateway selection is, in general, the process to determine a media gateway, such as the first or the second network entity 31, 32, which is most suitable for a given traffic case. This enables flexible routing of the payload within the core network. It is a complete procedure from selection of a media gateway out of a so-called media gateway group (MGG) until the seizure and capturing of an access termination in the media gateway. It is noted that if the seizure of bearers in the media gateway group fails, i.e. all media gateways out of the media gateway groups were tried, then the media gateway group selection is initiated from the start and may be repeated several times (i.e. media gateway polling).
From the above description it becomes clear that media gateway polling works in case an error occurs early in the sequence of exchanging network addresses, for example in conjunction with sending the request message 111 or receiving the response message 112′.
However, as shown in FIG. 1C, it may also be possible that a communication failure occurs at another stage in the sequence, for example in conjunction with the second response message 132′ (e.g. MOD.Rep). In such a situation, the call switching entity 20 would again send its request message 111 to the first network entity 31. For the first, this first network entity 31 provides its own transport layer address as the first network address with its response message 112 as shown and described in conjunction with previous Figures. The call switching entity 20 also continues to forward this first network address to the call request entity 10 (assignment request message 121) and the call request entity 10 forwards its own network address as the second network address with its assignment complete message 122.
At this point, however, the call switching entity 20 may either be unable to contact the first network entity 31, or may, albeit being able to send the respective second request message 131 (MOD.Req) to the first network entity 31, receive an error code with the second response message 132′. For example, the response message 132′ could comprise an error code which indicates that the first network entity 31 is no longer able to handle a call communication to the call request entity 10 due to, for example, network congestion or codec incompatibility. In such a case, the only choice left could be to repeat the second request message (e.g. MOD-command) towards the same network entity—even if several network entities, such a media gateways, may have been included in a respective group (media gateway group—MGG) that is associated with the call request entity. This is because the network address of the first network entity (or a respective port number) has already been provided to the call request entity in the respective assignment request message.
This situation could, however, trigger a sequence of error messages 141 and 142 via the call request entity 10 to the mobile terminal 1 indicating that no call communication can be established, which would be equivalent to a call rejection. Such a rejection would, in any way, also imply that the user of the mobile terminal 1 needs to initiate a further attempt to establish a call. The requirement of a further manual call initiation is, however, unacceptable in case of prioritized call setup for NS/EP-calls.